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[57] ABSTRACT 

The present invention includes a method and apparatus for 
distributing music to local, digital, electronic jukeboxes. In 
particular, a complete menuing system is stored in a central 
storage location. A portion of the complete menu is stored 
locally at the jukebox, depending on user demand. A juke- 
box selectively requests the transmission of songs from the 
central storage location using a variety of communication 
means based upon usage data with respect to songs and the 
menu. The request can be initiated by the jukebox and can 
occur automatically based on statistics compiled by the 
jukebox representing user demand. The central storage loca- 
tion processes the requests and schedules individual requests 
from each jukebox to coordinate transmission of music to 
multiple locations simultaneously. In addition, the central 
storage location periodically updates the local jukeboxes 
with a list of new releases, during which time the jukebox 
can also download the miisic. A portion of the complete 
menu is stored locally at the jukebox, depending on user 
demand. The jukebox also includes secure hardware used to 
decrypt and encrypt music and monetary certificates, to 
prevent improper use or copying of music. 

29 Claims, 15 Drawing Sheets 
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SYSTEM FOR SELECTIVELY 
DISTRIBUTING MUSIC TO A PLURALITY 
OF JUKEBOXES 

BACKGROUND OF THE INVENTION 

1. Field of the lovention 

The present invention relates to a music distribution 
system for jukeboxes. More specifically, it relates to a 
system in which a jukebox selectively requests transmission 
of specific songs from a centralized storage location based 
upon usage information, and a system which coordinates 
transmission to optimize channel bandwidth. 

2. Discussion of the Related Art 

Conventional jukeboxes play music from records or com- 
pact discs containing several songs. The records or disks are 
stored locally at the jukebox and are physically selected and 
played with these jukeboxes. The user views a display listing 
song selections contained in each record or disk. The user 
then selects a song to be played by depositing money into the 
jukebox and pushing keys which represent the desired song. 
A record or disc changer in the jukebox selects the appro- 
priate record or disc and transfers it to the player, which can 
take as much as 30 seconds. 

There are many deficiencies in conventional jukeboxes. 
ITie most significant problem relates to music selection. The 
users are limited to the songs on the records or compact discs 
which are physically present in the jukebox. However, much 
of the music on these records or discs may be unused. This 
is because less popular songs are often included on the 
record or disc with more popular songs. Jukebox records 
typically have two songs, one on each side. Compact discs 
may have many songs. Generally, only a couple songs on a 
disc are popular and played often. The remaining songs are 
merely part of the disc and are not played. Estimates indicate 
that 80% of songs in a jukebox may be unused. This wastes 
space in the jukebox which could have additional popular 
songs. Also, it is not easy to customize song selection for 
specific clientele at a location. Different establishments have 
clientele which often desire different types of music, or 
particular songs. There is no easy mechanism to determine 
the tastes of the users at a specific location. Therefore, the 
jukebox owner will use general popularity information to 
select songs. Alternatively, certain studies, either formally 
by researchers or informally through the establishment 
operator, will be used to select songs. Such studies also have 
deficiencies due to sampling problems. 

After music is selected, updating the music is time con- 
suming and expensive. The records or compact discs must 
be manually updated by replacing the records or disks. Each 
copy of the record or disc must be purchased and then 
installed in the jukebox. The title list also must be updated 
manually when discs are changed. 

Costs of installing and maintaining a jukebox can be 
extremely high. A jukebox can hold as many as 100 discs or 
records. Installation of the jukebox requires purchase of a 
complete set of records or discs. Additional purchases must 
be made in order to change the music. Also, since a jukebox 
includes many moving parts, breakdowns are common. 
Breakdowns often occur with the money reception portions 
or record/disc movement portion. Maintaining the jukebox 
requires visits from specialized technicians. Since the cost of 
playing a song is typicaUy low, a jukebox is too expensive 
for an establishment in which songs are not often played. 

Therefore, a need exists for a jukebox which permits 
simple customization of song selection for specific loca- 
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tions. A need exists for a jukebox system which eliminates 
manual selection and changing of songs. A need exists for a 
system which reduces the costs of operating a jukebox. 
In personal music listening, a tape, record or disc is played 
5 on a simple system. The possible songs are limited by the 
songs owned by the user. It is expensive to have a large 
music library, since each song must be purchased. Also, song 
selection can be quite time consuming with a large library, 
since the songs must be selected manually. The costs of a 
jukebox prevent the user from using a jukebox as a personal 
music playing device. Additionally, if a person rents a 
jukebox, such as for a party, songs cannot be consecutively 
played. Rather, a delay is required between songs in order to 
change discs, which is typically between 8 and 30 seconds. 
Therefore, a need exists for a jukebox system which is 
inexpensive and can operate as a personal music player. A 
need also exists for a system which can play selections 
consecutively, and can include transition effects, such as 
fades. 

Some of the difficulties of conventional jukeboxes have 

20 been overcome by different variations of jukebox type 
designs. Generally, these systems are one of three types: 
on-demand streaming, near on-demand streaming, and 
downloading. In an on-demand streaming system, the user 
selects a specific song from a central or general library. The 

25 song is then immediately performed. On-demand streaming 
requires a high speed data channel, at least 128 to 256 kbps, 
between the server and the jukebox. Accommodating this for 
more than a local area would be prohibitively expensive. 
Such a system also requires an extremely high speed 

3Q modem, which is also expensive. 

Near on-demand streaming uses a variety of channels to 
transfer songs to a location for performance. The user can 
then select one of the multiple songs available on the 
channels, similarly to selecting a television or radio channel. 

35 In order to have the same replay possibilities as a jukebox, 
each song would have to be replayed approximately six 
times simultaneously. As with on-demand systems, the nec- 
essary bandwidth for real time transfer of music far exceeds 
today's technologies. 

40 In a download system, music is loaded a jukebox from a 
central location. The music is stored at the local location for 
fiiture playing. A computer jukebox is an example of such a 
system. In a computer jukebox, the songs are digitally stored 
in a memory. For example, in U.S. Pat. No. 5,355302 to 

45 Martin et id., new recordings are downloaded into the 
memory of each computer jukebox. Old recordings are 
erased from the memory to create space for the new songs. 
The jukebox monitors and stores information regarding the 
number of times each song has been played. The information 

50 is collected at a central location which uses this information 
to calculate royalty payments and to determine which songs 
are less popular and need to be replaced in the jukebox. The 
jukeboxes are managed remotely by a central management 
system using modems and public telephone lines or radio 

55 frequency transceivers and anteimas. The central manage- 
ment location also contains a master catalog containing 
information about each song record it stores. The central 
management system monitors the jukebox, determines avail- 
able memory space in the jukebox and transmits the new 

60 songs and catalog information to update the jukebox. The 
computer jukebox stores songs and graphics locally with 
information about the songs. The jukebox can initiate com- 
munications with the central management system at prede- 
termined times or if the jukebox determines that an event has 

65 occurred that the management system should be aware of. 
In known computer jukebox systems, the central manage- 
ment system determines which songs need to be replaced 
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and which jukeboxes need to be updated by using new song 
request data entered by customers to aid in determining 
whether new song data should be downloaded to the juke- 
box. The jukebox contains a classification hierarchy which 
allows the user to find a song of interest. However, existing 
systems do not include mechanisms for allowing the user to 
select songs by classes of music types and do not provide 
information at the local jukebox relating to song availability 
at the central storage location. In addition, automatic mecha- 
nisms are not used to update songs based on user selections. 
Therefore, a need exists for a system which can automati- 
cally update songs based upon user preferences. 

In existing systems, songs are transferred from a central 
location to the local jukeboxes through a variety of media, 
including satellite broadcasts, RF transmissions, telephone 
line transmissions and physical transfers of disks. Songs are 
generally transferred individually to each jukebox. The large 
files associated with downloading music files can be pro- 
hibitively expensive, inefficient and time consuming. The 
average size of a compressed song is on the order of 50 
megabytes. The cost to transfer the large files including 
songs, can be prohibitive for a computerized jukebox using 
a central music storage location. In order to compete with 
traditional jukeboxes, the cost of music distribution must be 
similar to that for purchase of new compact disks. 
Additionally, the cost for the equipment to provide the 
communication of the songs to the jukebox can be high. 
Transferring songs over a telephone line using modems is 
expensive, particularly if a long distance telephone connec- 
tion is necessary between the jukebox and the central 
location. Although high speed modems are fairly 
inexpensive, in many locations, the telephone lines may not 
be sufficiently clear of noise such that the high speeds can be 
achieved. Higher bandwidth or speed telephone lines may 
not generally be available in many locations, and generally 
cost more. ISDN communications have even higher speeds, 
but are more expensive both for the telephone line and for 
the equipment. Other types of high speed modems, such as 
ADSL modems, also are significantly more expensive and 
connections are not widely available. Satellite receiver costs 
is also high, both for the equipment and for the ongoing 
service. Songs may also be transferred through the Internet, 
but significant delays are possible. The computer jukebox 
still needs to be connected to the Internet through some type 
of modem, although a long distance call may not be neces- 
sary. Therefore, a need exists for a more efficient transmis- 
sion system. In order to compete with traditional jukeboxes, 
the music distribution system must include a low cost for 
both the communication lines and for the communication 
equipment. Also, as the size of the system grows, significant 
increases in the cost of distribution eqmpment must be kept 
at a minimum. 

Also, computer jukeboxes typically have a closed 
architecture, i.e., the jukebox is associated with a specific 
music distributor and distribution system. This creates a 
large dependency of the jukebox on the distribution system. 
If the distributor ceases to exist, the music in the jukebox 
may not be replaceable. Similarly, spare parts for repair may 
cease to exist. Therefore, a need exists for an open archi- 
tecture for a distribution system. 

Finally, a system of computer jukeboxes must be secure. 
Since songs are digitally stored in a modifiable memory 
device, the songs can be copied to other devices. Also, 
unauthorized songs may be loaded onto a jtikebox. The 
music distribution system must provide a mechanism for 
security of the songs to ensure a fee is paid for the copying 
and distribution of the music. The payment mechanism must 
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avoid credit or debit falsifications. Several secure payment 
mechanisms such as smart card, debit card, credit cards, etc. 
have been used. These mechanisms may provide a satisfac- 
tory security as long as the coimections between the pay- 
5 ment mechanism and the electronic control can not be 
accessed by hackers or the software that controls the pay- 
ment mechanism cannot be modified. 

However, for jtikeboxes, the jukeboxes operators must 
have access to the connections because they need to service 
10 the machines. Thus, connections can be cut and payment 
mechanisms can be emulated thereby fooling the electronic 
control. From the other side, the software that controls the 
payment mechanism can be easily modified and fooled. In 
this way, hackers avoid paying the fees. 

Therefore a need exists to create a more secure payment 
mechanism that is still secure even if the payment mecha- 
nism or software controlling it, is violated or fooled. 

SUMMARY OF THE INVENTION 

20 

The deficiencies of existing jukebox systems are substan- 
tially overcome by a jukebox system according to the 
present invention in which individual songs are digitally 
stored. Music can be transferred from a central storage 

25 location to the jukebox, to update the music without a 
physical replacement. Amtisic hierarchy system exists in the 
jukebox for determining customer preferences in order to 
automate music selection during updating. Also, a unique 
distribution system is used between the central location and 

30 the jukebox which improves on bandwidth utilization for 
transmission. 

Accordingly, it is an object of the present invention to 
provide a jukebox system which uses a statistic replacement 
algorithm working wi± different memory hierarchies, a 

35 scheduling algorithm, and conventional means of commu- 
nication with addressable and broadcasting capabiUties. 

It is a further object of the present invention to provide 
newly installed systems with music on demand and to 
provide all other systems requesting music based on local 

^ user needs at deferred times. The deferment results in 
supplying music more efficiently and at a lower cost and by 
combining requests from mtiltiple locations for a single 
transmission of music to the multiple jukeboxes simulta- 
neously. 

45 

It is a further object of the present invention to have a 
jukebox programmable with different payment methods to 
allow advanced payments and to allow automatic access by 
the jukebox to the central storage system. 
5Q It is a further object of the present invention to store a 
portion of a hierarchial menu at a local jukebox location and 
to retrieve additional portions of the menu based upon local 
xiser accesses. 

The present invention also allows songs to be placed on 
55 the local jukebox based upon user inquiries into various 
areas relating to availability. The local jukebox automati- 
cally determines music to be retrieved at certain locations 
and selectively downloads music based upon actual user 
preferences at that location. 
60 It is another aspect of the invention to create a system of 
music which has a low cost, both for equipment and service, 
for communicating songs to the jukebox and information to 
the central location. According to this aspect of the 
invention, one of the jukeboxes, designated a master, can 
65 operate as a regional service center. Music is communicated 
from the central storage location to the regional service 
center. Music may be stored at the regional service center or 
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further transmitted to other jukeboxes. The subsequent Electronic Titles (VET). A VET is digitally encoded into a 

transmission from the regional service center to the slave secure digital envelope to be used for mail distribution or 

jukeboxes can be over local telephone lines at lower speeds electronic transmission or storage and can only be opened by 

with reduced costs. Similarly, the individual jukeboxes can authorized users. The VET envelope contains diverse object 

communicate inforaiation directly to the regional service 5 types with relational links, and packaging and accounting 

^^gjjjgj. information. VETs can be sold, purchased, stored, rented, 

.* . ^ , . . . distributed, executed, reproduced, produced or inter- 

It is another aspect of the mvention to provide a music ^^^^ Execution of an object type in a VET results in 

distribution system which is compauble with the use of ^^^^ perception of texts, graphics, sounds, videos, three 

compact disks already owned by a jukebox operator. Tht dimensional objects, etc. Thus, VETs can form the storage 

computenzed jukebox can have an mterface to connect with lO ^^^^^^^ ^ ^.^^^^ .^^^^ ^ach song is stored as a 

commercial compact disk changes. Album covers and song ^ ^^^^ ^^^^ ^^^^^^^ ^^^^^^ 

names can be entered or scanned into the memory in the Reproduction of an object type in a VET 

jukebox^ If the user selects one of the albums or songs on ^^^^^ reproducing the object types in a media, such as 

one of the compact disks the jukebox communicates to the ^ . ^.^^^ (CD), tapes, paper 

CD changer to select and play the appropriate song. 15 s ^^^^^^ ^^^^ ^^^^^^^ sculptures, etc. Hius, it 

It IS another aspect of the mvention to provide a secure ^Iso possible to reproduce a song in another format so that 

environment for the transfer of music and other sensitive (he customer can obtain an actual copy, and the jukebox can 

information (such as monetary certificates) for purchasing function as a retail distribution center. Royalty payments for 

songs or paying for services from the central location to each uansmission of copies can be ensured through use of the 

of the computer jukeboxes. The system includes secure payment mechanism discussed below, 

hardware in each of the jukeboxes which is used to encrypt ^ mustrates a music distribution system using VETs 

and decipher the music and other sensitive mformation (such according to an embodiment of the present invention, 

as monetary certificates) for purchasmg songs or paymg for including access methods between a jukebox and a central 

services provided to that jukebox. The music IS stored man ^^^^^^^ location, FIG. 1 contains a VIP architecture in a 

encrypted format which prevents copymg to other locations, chenl/server environment. Three main elements comprise 

mcludmg other jukeboxes within the system. The secure yjp^ including the Intelligent Terminal (IT) IT1-IT9, the 

hardware is used to ensure the authenticity of distributed Operation Service Centers (OSC) Rl, R2, Gl and the 

music and proper payment for the music. Communication Means (CM) CM1-CM9. Even though a 

RRTFF OFSCRTPTTONS OF THE DRAWINGS 30 single distribution system is illustrated, multiple distribution 

BRIEF DESCRIFHONS OF IHb DRAWINOb ^^^^^^^ distributing music to any of the ITs. 

FIG. 1 is a schematic illustration of a music distribution For example, as illustrated in FIG. 1, IT4 can receive music 

system according to an embodiment of the present inven- through either Rl (a primary distribution channel) or R2 (a 

tion. secondary distribution channel). Similarly, each IT may be 

FIG. 2, comprising HGS. 2a-2c, is a schematic illustra- 35 connected to more than one independent network Thus, 

tion of local music structure including a hierarchy of classes each IT can opei-ate in an open architecture which is not 

of music hmited to a single distnbutor. The IT can operate like a 

* . ^ . .„ . - 1. . r computer in that it can include instructions for connecting to 

HG. 3 IS a schematic Illustration of a queue cham for ^^^^^^^ distribution networks. A single network is iUus- 

requested music m a statically assigned channel server. ^^^^^ j discussed below. 

HG. 4 is a schematic illustration of a queue cham for embodiment of the present invention, the IT is a 

requested music m a dynamically assigned channel server. Personal Jukebox (PJ) that can be capable of supplying 

FIG. 5 is a schematic illustration of a queue chain for music execution on demand 95% of the time at no cost, 

requested music in a delay lock out channel server. Personal Jukebox does not limit the devices to in-home 

FIGS. 6a and 6b illustrate the process for initialization of 45 locations. Rather, it refers to the capability to select songs 

the secure hardware in a security mechanism of the present according personal tastes and desires of the customers at a 

invention. specific location. However, the distribution system of the 

HGS. 7a, lb, and 7c illustrate the process for distribution present invention can be used to provide music through a PJ 

of music using the security mechanism of the present individuals in-home. The high capability of the PJ to 

invention 50 execute music on demand is achieved by sensing the music 

HGS. fia. 8b. and 8c iUustrate the process for distribution ^^'^'^ "^^^l '^^'^'^ below The 

of monetary certificates in the security mechanism of the ."^f ">f ^^f"!^ ^8^^ ^ '° 

resent invention physically place VETs m a storage platforms closer to the 

. , end users which willlikely request such VETs, The Regional 

HG. 9 Illustrates a block diagram of a second embodi- g^^^^^ j^^^ ^ ^ use the local demand sensing 

ment of the music distribution system accordmg to the information to determine local popularity demand, while the 

present mvention. qI^^^^ ^^^^j. information to determine regional 

DETAILED DESCRIPTION popularity demand. Each PJ uses individual demand sensing 

to determine local storage of VETs. 

The present invention relates to a jukebox with digitally go The PJ platform (any of IT1-IT9) contains a CPU hard- 
stored music, and a music distribution system for replacing ware box, a massive storage system, and a real time oper- 
music in the jukebox. It includes an apparatus and method ating system and drivers for the hardware devices. The CPU 
for requesting certain music stored at a central storage hardware box is based on PC-like hardware or set-up-box 
location and transmitting it to local jukeboxes, type hardware. The massive storage system is large enough 

The present invention more particularly relates to a Vir- 65 to store more than 200 compressed songs, as VETs, with 

tual Inventories with Perpetual Reproduction and Execution associated data types (text and graphic images), or generally 

of Electronic Titles (VIP) architecture for managing Virtual has about 1 Gigabyte storage capacity. The massive storage 
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system is scalable to the user's needs. Since songs can be extremely high speed bandwidth. This method is actively 

individually selected for inclusion (or deletion) from the being developed in the US by the increase in fiber optic 

storage system of the PJ, only desired songs need to be communications. 

stored. No storage is wasted on song3 which are not desired, yv? uses the terrestrial, wireless technologies Multipoint 
The Global Distribution Platform Gl in FIG. 1 consists of 5 Multichannel Distribution Service (MMDS) or Local Mul- 

a LAN connected to a WAN. This Global Operational tipoint Distribution Service (LMDS) for access to the OSC 

Service Center Gl is comprised of a master server, hierar- -j^e MMDS is unidirectional with a high bandwidth. LMDS 

chical storage subsystem a communication server a con- bi-directional based on cellular-like technology, 
nection eqmpment to a pubhc or private network, and a VET 

facto rv ^ satelhte receiver and is not mteractive. 

Regional OSCs Rl, R2 are similar to the Global OSC Gl, '° ^^s are broadcasted continuously and the ITs automati- 

excepl that they do not require a VET factory. Regional <f^y ^f^^ ^^^.^^ they want to download based upon local 

OSCs Rl, R2 are geographically closer to the ITs that they demand statistics as discussed below ITs are charged a 

are serving. Thus, they can provide a faster, and generally P^nodic fee or are charged for the number of VETs that are 

less expensive, source for any given VET. As noted above, ^^own loaded. The OSCs have the abiUty to disable/enable 

the demand information from each of the PJs corresponding the IT downloading (reproduction) and execution capabili- 

to a Regional OSC can be used to determine specific VETs ties of the IT. 

to maintain at the Regional OSC. Regional OSCs, such as IT9 uses a portable computer to capture transaction and 

Rl, R2, can operate as alternate nodes in the VIP network statistical information from the IT, and downloads contents 

and a OSC replacement for other regions so that if a node in required by the IT. The connection between the IT and the 

the VIP network fails, alternative routes and alternative OSC is through a port or LAN. 

Regional or Global OSCs can be accessed. While a single ^ communication server or access server performs the 

level of OSC is illustrated between the Global OSC and the interfacing fiinctions of network protocol translation, speed 

PJs, multiple levels may be used. The demand information matching, buffering, and network packet routing between 

is used at each level to maintain tiie most popular songs for the ITs and OSCs. When using sateUite deUvery to the ITs 

the lower levels. the network carrier is connected to the OSC by means of a 

Tlie OSC provides operation services to the ITs. In HG. high speed Tl or El link (or other high speed link) from the 

1, different options for the ITs to access the OSCs are shown communications server to the satellite up-link, where data 

CM1-CM9. There is a high volume, high speed distribution will be sent to the satellite for delivery to the geographically 

of VETs from the OSCs to the ITs. In addition, there is a low distributed ITs. The communication server and the OSC are 

volume, low speed exchange of information from the ITs to internally connected to a Master server through a network 

the OSCs. The information exchanged includes the IT hub which performs the interconnection of all network 

sending a VET request to an OSC. an IT accessing statistical devices to guarantee a high network throughput speed, 

information at the OSC. an OSC accessing sales information y^j f^^^^^ jhe Global OSC Gl produces VET 

from an IT, and an OSC making a remote control diagnostic. envelopes which are transferred throughout the system. The 

etc. If a Regional OSC fails, an IT can connect to another y^j ^^^^^^ multimedia workstations with 

Regional OSC. or to the Global OSC for services. ^^iting and authoring capabilities, temporary storage, con- 

ITl in FIG. 1, uses an asynchronous analog telephone line xcni capture units and an internal connection to the OSC 

for the exchange of information, ITl sends a request for a network hub. The workstation is connected to the LAN and 
VET to tiie Regional OSC to reduce Uie cost of the telephone ^ )VAN through the network hub so that tiie workstation can 

call. The Regional OSC Rl then forwards the request to the access tiie master server and the external WAN devices. The 

Global OSC Gl, which in turn up-links the requested VET contents of the VET can include text such as an album name, 

to the satellite. The satellite tiien transmits the requested gong name, author, producer, date, serial number, royalty 

VET to tiie m sateUite receiver. In tiiis embodiment, only owner, etc., an image such as an album cover, or audio such 

a receiver, antenna, down converter and a phone line are as the song or digital file. The workstation creates tiie VET 

needed locally. and sends it to tiie Master Server through the Network Hub. 

IT2 uses an integrated digital switched network for tiie The Master Server in turn updates tiie VET data base. The 

exchange of information and VET distribution. This network workstation has ports to connect to captm-e devices, such as 

requires a modem and is currentiy becoming standardized CD players to caphire songs. The capture unit converts a titie 

among service providers. into a signal, 

IT3 uses removable discs to store all information related in the present invention, a VET envelope is distributed as 

to accounting, sales, user VET requests, etc. The disc is a single unit. The envelope contains a group of VETs of the 

mailed to the contracted OSC where the information is same or different data types liked together. Normally, the 

loaded into databases to process the information. The OSC VETs in an envelope will have a title relationship. For 
then generates a custom made disc with tiie VET requests for 55 example, an envelope can be created from an album so that 

the specified IT user. Alternatively, tiie OSC may generate a the envelope contains five songs from tiie album. The 

generally programmed disc with common distributions, such envelope would contain 5 compressed and encrypted audio 

as for new songs. tities, 5 uncompressed non-encrypted song tides, each linked 

1T4 uses a cable modem to exchange information and to its respective audio titie, one uncompressed album title 
request VETs. Currentiy, there is no uniformity among cable liked to each of the song tities and one compressed non- 
operators which makes this method of accessing the OSC encrypted cover page linked to the album titie. 
difScult. Also, some cable operators do not have bidirec- xhe access method between a PJ and a central storage 
tional data transmission capabilities, location as shown in FIG. 1 includes tiie following steps. 

ITS uses an asymmetric digital subscriber line to The OSC periodically broadcasts to all locations a list of 
exchange information and request VETs. 65 new songs available for distribution. The Personal Jukebox 

IT6 uses switched digital video or a hybrid-fiber coaxial (IT1-1T9) downloads the list of new songs. The PJ deter- 

cable modem to access the OSC, which allows for an mines the users' demand by capturing the users' require- 
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ments and processes the demands statistically. The PJ then When a portion of the hierarchy is retrieved, it will not 
determines which new titles are convenient to download. necessarily retrieve everything under it. Rather, it will 
Previous to the attempt to download, the PJ woiild have been retrieve one level and portions of lower levels. Additionally, 
loaded with credits through a bank payment, bank deposit or portions of the hierarchy and song? which are not accessed 
a PJ fund collection mechanism, such as coins, bills, smart 5 as often are deleted in order to make space for new portions 
cards, etc. Once the credits are deposited, the PJ is auto- and songs. Thus, the jukebox is automatically updated with 
enabled or not disabled by the OSC satellite transmission to ^^^^ interest to the cHentele for that particular location, 
download a number of song titles. As a title is downloaded, ™^ ^ , - . . 1 i_ j -j*!. r 
the number of credits is decreased. The PJ downloads only system also optmiizes the channel bandwidlh for 
titles that it has selected, as long as credits remain. Each of transmission of mfomiation from tiie central location to the 
the jukeboxes locally stores a portion of the music available separate jukeboxes. Each request for additional portions of 
in the system and can play that music. Music not on the the hierarchy or for specific Utles of songs includes a tune 
jukebox can be retrieved fi-om a central storage location for delivery. When information is requested so that times for 
through any electronic transfer mediiun such as CM1-CM9 delivery overlap, the information can be simultaneously 
shown in FIG, 1. Only music which has been enabled U-ansmitted to muhiple jukeboxes. This is particularly rel- 
through the use of the credits can be received, deciphered evant when the information is transmitted by satellite or 
and played. When a PJ runs out of credits, songs are not through a computer network. It permits a broadcast trans- 
enabled. Also, music which is copied from another source, mission to multiple final locations, 
such as another PJ. will not be enabled. Thus, improperly qqc embodiment of the present invention, the Song/ 
copied songs cannot be deciphered or played. Other security ^^^^ ^over ratio is the number of productive songs in an 
features are discussed below, 20 ^^^^ productive songs are classified in two types: 
no. 2, which comprises FIGS. 2fl-2c iitorates a local ^^^^ jj^^t gQ^^ j^e monthly sales and those that 
music structure for determimng demand information and ^^^^^^ remaining 20% of sales. Based on studies, the 
performmg song selection^ Such a structure is included at ^^^^ ^^^^^^^ ^^^^ ^^^^^ 

each level m the VIP based upon information from a lower ■ , . ... * on/w r *u *ui 1 

uri e ' jukeboxes which generate the 80% of the monthly sales. 

level. The structure includes a hierarchy of classes of music 25 Vu ^ « tv.« ti,^ a™o„« D^^f^^^^^ 

.... - . , / . T \ J i_ * Those songs are Top Performers. The Average Performers 

with levels for music types (such as Latin) and sub-types ^^jj,^^ ^^^^ ^^i^^ ^^J^^^^ ^^^^ 

(such as bamoa, ialsa, Merengue;, alpums, ana sonp. bacp 20% of sales. The total number of productive songs is the 

jukebox includes only a portion of the hierarchy which .ombination of the Top Performers and the Averlge Per- 

would be locally accessible. The entue hierarchy would be ~ ™ ^ '„„l„t^^^^ A.^^tu,^ 

, , J . ^. * 1 1 n • 1 J- * u *• formers. The OSC inventones are loaded with productive 

located in the central location. Regional distribution 30 ^ ^ .u^^u,, nio/ «f «f iu^ ™ 

„^ . ^ ^ • . J 1, songs only, thereby eummatmg 73% 01 the 01 the non- 

locations, such as Rl R2 m FIG. 1. may include all or a l^^^^l ' ^he Top and Average Performers, 

portion of the hierarchy. The portion of the hierarchy on the ^^^^^^ p^^/^^ ^^^^ periodically 

jukebox IS then traversed m order to select songs that are ^..^ by the central storage location without any 

ocallyavaUable to be played. -nje user selecK a music type. requests from the jukeboxes, 

then a sub-type, an album and then a song. Only songs for 35 ^ . . ' . , ^ . ^ , 

which VETs are stored can be locally accessed. Even though transmission, one bandwidth requirement is nee- 

a user selects an album, not all of the songs on the album essary for the iransmi^ion of the Top and Average Perform- 

may be stored or selected. Thus, the popular songs on an Monthly Premiere songs, which is a non mteractive, 

album are stored while less popular songs are not. 'iJ^^'e transmission which can be programmed to occur in 

In order to determine user preferences, the user can 40 programmable periods, such as twice a month. All local 
traveise the hierarchy to select types of music or specific the non-mteracbve broadcast of the new 
songs which are not currenUy available and which would be f^' ^ .tiUes can be actuaUy do>*^loaded by the juke- 
deskable. These songs can then be downloaded to the ''"f? the broadcast tmie. A second bandwidth 
. 1 . r *u * 1 / • i\ 1 in- • 1 u reqmrement is necessary for the interactive, update trans- 
jukebox from the central (or regional) location. The jukebox ? . i_ *u • 1 u * *i- • x/T-nn c *u 

, ^ . . J- *L u c *• *i- * mission when the jukeboxes request their VETs from the 

mamtams statistics regardmg the number of times that a 45 . , ^ , j 4,.* . 

J • *i- u- u • • J u Tr*u J • OSCs based on user demand. This often occurs when a 

node in the hierarchy is reviewed by a user. If the node is ... , • . 

J • i_ r / -^u -^u- • lukebox IS installed in a new location. Both the interactive 

reviewed a certam number of tunes (either within a given ^ . .... j • i. i 

^ . * i?*t-**i ur and non-mteractive modes can run simultaneously, 

time period or as a certain percentage of the total number of . , . 

nodes visited), information which is below that node is Th^ ^^^ults m a Coincident Overlapping Concurrent 
retrieved fi-om the central storage location. Thus, there may 50 Delivery (COCD) system to minimize the bandwidth 

not be any songs locally from a type of music. However, as requirements and the cost of transmission and to improve the 

users access the hierarchy and select each type, its statistics availability of transmission of VETs. Different cHents may 

increase until lower portions of the hierarchy should be request the same VET m an overlapping tune. The more 

retrieved. The number of hits necessary in order to request overiappmg time that exists, the more chances there are that 
additional portions of hierarchy or of certain songs from the 55 "^^re chents will share the same VET delivery. Overlapping 

cenual location can vary based upon the objectives for the time is promoted by offenng the lowest cost for the chents 

jukebox. More rapid retrieval, such as direct on-line access, tolerating the longest transmission delay range, 

would naturally be more expensive. Alternatively, the sys- The COCD is comprised of a queuing system, 

tem can request that the new music or hierarchy be sent distributors, channel servers, a COCD controller and a 
within a given time, such as two days. As discussed above, 60 request conflict handler. A queue includes VET_Groups 

some songs may be periodically broadcast from the central which represent one or more VET_Transmission_ 

location. The hierarchy may also be similarly broadcast. Requests. The queues have a concatenation pointer to move 

With this structure, when a jukebox determines that a song the VET_Groups that complete their wait time in the queue 

or portion of the hierarchy is to be retrieved, it monitors the to another queue or to a Distributor. The Distributor sends 
broadcast until the song or portion of the hierarchy is 65 the VET_Group to a Channel Server for transmission, 

broadcast. When detected, the jukebox will download the In the COCD system, an IT, such as a Personal Jukebox, 

desired information from the broadcast. sends a VET_Transmission_Request when it requires a 
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VET to be transmitted. Queues, Groups and Requests have more precise wait time before transmission. This feature is 

unique instruction parameters. The class parameters include: particularly suitable for broadcast transmission systems, 

instructing the COCD system how long the VET should wait which require some type of deterministic transmission time, 

before transmission, indicating during what time frame the For example, with non-interactive satellite transmission (ITS 

transmission should occur, instructing the COCD system 5 in FIG. 1), the OSC must transmit the song names (the index 

about communication savings, and indicating when the hierarchy) of new songs which are available. The system 

queue becomes enabled for transmission, etc. The availabil- ""^V d^^^y ^ time such as one week, for each jukebox 

ity parameters include indicating to the COCD the worst ^o determme demand for each of the new songs before 

case delay window expected for a group in that queue. ^^^l^^^f ' ff^ themselves^ 

rru r^Ar-r. » 11 • * t u* u f 7u nr^r-T^ in FIGS. 3 and 4, queues 1 and 4 have been assigned a 

Hie COCD controUerisataskwhich performs the COCD lO ^^^^^^ ^^^^ ^^^^^^ Distributor 1. Tlie other queues in 

mtelhgence and operation. It creates VET_Groups, inserts pj^g 3^5 concatenated to the Next_State or the next 

and moves them from queue to queue, updates the param- ^^^^^ example, in FIG. 3, the output of queue 3 goes 

eters and arranges the scheduling. the input of queue 2 and the output of queue 2 goes to the 

The OSC will invoke the COCD upon receipt of the IT's input of queue 1. Queue 1 occupies 66% of the time of the 

VET_Transmission_Request, The COCD determines channel server, while queue 4 is using only 33% of the 

which VET_Groups are pending for transmission with the channel service's attention. 

same VET name and compatible instruction parameters. A queuing system of the present invention allows for 

new group is created and inserted in the queue if the the more efiEcient transfer of music to multiple locations, 

VET_Transmission„Request and the VET_Group do not saving both time and money. 

have the same class parameters. Otherwise, the VET_ 20 p^^nal Jukebox in the present invention may be for 

Transmission„Request is stacked in the group. If a shorter ^-ther commercial or home use. For the home version, the 

delay time is requested, then the group is updated with the ^^^^^^^ communication equipment, funds collection units 

new request availabiHty parameters and all of the stacked the sound subsystem are optional and can be added at 

requests are moved to a higher availability queue that will since the home user may have a television as a monitor 

matches all the instruction parameters. If a shorter delay ^ ^^^^ ^^^^ ^^^^^^ connected to the PJ. 

time is not requested, then the request is stacked in the pj^g ^^^^ -jj^^^^^^ operation of a security system 

group. Tins ensures that only one transmission wiU occur for ^ embodiment of the present invention. The 

aU the pending requests stacked and waitmg m the same ^ ^ ^^^^^^ . . 

group for the same VET transmission. ^^^^ ^^^^^ ^ ^ p^^^^ j^^^^^ ,j ^^^^^^^ 

The COCD Distributor chooses VET__Groups from one thorized storage or playing of music with the Personal 
or more enabled queues and distributes them to one or more Jukebox. It also prevents improper use of monetary certifi- 
channel servers. The Distributor balances the choosing and ^^jes used for purchasing song copies or other types of 
distributing as a function of the weight of the queue and the products or services. In the security system of the present 
throughput of the channel server by implementmgdistnbu- invention, the songs in each jukebox are stored in an 
tion functions such as round robin, fixed priority, daisy encrypted format which prevents them from being trans- 
chain, etc. ferred to another jukebox or other storage medium. Music 

The channel server in the COCD receives the groups from which is transferred to the jukebox from one of the OSCs is 

the Distributor and performs the actual VET transmission. also encrypted. The decryption of the transferred music 

FIGS. 3, 4, and 5 illustrate an example of the COCD system ^ requires sufficient monetary credits; otherwise, the VETs 

with several VET requests waiting. There are 6 different cannot be decrypted. Similariy, the coordination of the use 

queues configured in the COCD as shown. of monetary credits must be controlled by the OSC to 

In FIG. 3, queues 1, 2, and 3 are concatenated and prevent imauthorized increases in credits, 

illustrate optimizing availability of statically assigned chan- Each PJ includes secure hardware, which, according to 

nel servers. If, for example, a VET_Group X is the first in 45 one embodiment is located on the audio card. The secure 

a queue and the higher availability queues in the chain are hardware, implemented in a monolithic format, is used to 

empty, the Distributor will pull the VET_Group X for encrypt and decrypt information. Since the secure hardware 

transmission, causing the transmission to occur ahead of is monolithic, only the input and output data can be 

schedule. This feature is especially suitable for communi- accessed. All of the digital inputs and outputs to the secure 

cation services where the channel servers are statically 50 hardware are in an encrypted format which prevents unau- 

assigned (continuous) because the OSC is charged whether thorized copying of the VETs or monetary certificates or 

the channel is used or not. The COCD reschedules the VET another sensitive data. 

requests to distribute them to optimize the use of the channel secure hardware for each PJ is unique, and will 

server time. decrypt and encrypt data differently. Therefore, the secure 

In FIG. 4, queues 4 and 5 are concatenated and illustrate 55 hardware is not transferable between different jukeboxes, 

optimizing transmission costs of dynamically assigned However, if the secure hardware for a jukebox becomes 

channel servers. By delaying the transmission of requested damaged, it must be repaired in order to retrieve and decrypt 

VETs, there is a reduction in data transmission and a lower the VETs stored by that secure hardware. A set of public and 

transmission cost, especially when channel servers are private keys are used to encrypt and decrypt VETs in the 

dynamically assigned because the carriers charge according 60 secure hardware. The OSC can maintain a proper index to 

to the amount of data transmitted. keys which can be used to repair or replace defective or 

In FIG. 5, queue 6 is by itself and illustrates optimizing damaged secure hardware. Preferably, a maintenance person 

for delay lock out. In this embodiment, there may be a will need to access the data (after entry of passwords or other 

precise time specified for a particular group in a queue. appropriate safeguards) at the OSC to download the neces- 

These VETs are time dependent, and are therefore not 65 sary keys for correcting the secure hardware. The initializa- 

promoted to a higher availability queue and are not stacked tion process for the secure hardware is illustrated in FIGS, 

with or into other VET groups. This delay lock out allows a 6a and 66. 
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As illustrated in FIG. 6a, an authorized center of the OSC 
generates an external IT (Intelligent Terminal or Juke Box) 
key, an external SH (secure hardware) key, and an external 
serial number for the secure hardware and corresponding IT 
(step 101). This information is encrypted (step 103) using a 
secret SH key (step 102) which is known exclusively at the 
OSC and the specific secure hardware. The encrypted 
information, called an initialization envelope, is then deliv- 
ered to the secure hardware of the IT. The initialization 
envelope can be transferred in different manners, including 
on physical disks, by modem, or through a broadcast to the 
specific IT. The secure hardware then decrypts the initial- 
ization envelope (step 106) to recover the external keys and 
serial number. No other IT knows the Int. SH key (105 in 
FIG. 6a) used to encrypt the initialization envelope, there- 
fore the envelope can exclusively be decrypted by the IT for 
which the envelope was generated. The secure hardware 
then determines whether the initialization was proper by 
comparing the external SH key with the internal SH key. If 
the keys do no match, then the initialization envelope has 
become corrupted (or is unauthorized) and the process 
terminates (step 109). Alternatively, the IT can be disabled, 
since an unauthorized modification was attempted. If the 
keys do match, then the internal IT key and internal serial 
number are updated with the new information from the OSC 
(steps 110, 113). If the secure hardware is being repaired or 
replaced, the external IT key selected by the OSC will 
correspond to the internal IT key for the device where the 
secure hardware is located. Since the VETs are encrypted 
and decrypted using the internal IT key, the repaired or 
replaced secure hardware can decrypt and play the previ- 
ously stored VETs. The serial numbers are used to control 
monetary credits as discussed below. 

The process for distributing VETs in connection with the 
security system is illustrated in FIGS. 7a, 7b, and 7c. A 
compressed VET 201, including a corresponding cost, is 
encrypted (step 203) at the OSC using a VET key 202 to 
create a VET envelope. The VET key can be based upon 
time to prevent a broken code from being used continuously. 
The VET envelope is then transferred to the proper ITs, 
where they are stored in the IT hierarchical storage. Since 
the VET envelopes are encrypted when stored they cannot 
be improperly copied by others. The VET envelopes can be 
copied to other ITs or other storage devices, but a proper key 
is needed to decrypt them. The secure hardware is then used 
to decrypt the VET envelopes. First, a proper VET key is 
selected (step 216) based upon the date of the VET envelope. 
The VET key is used to decrypt the contents of the VET 
envelope (step 218). If the IT has sufficient monetary credits 
(steps 207-209), then the decrypted VET is again encrypted, 
this time with the internal IT key of the secure hardware 
(step 224, FIG. 7b), The encrypted VET is again stored in the 
IT hierarchical storage. When a song is selected to be 
played, the VET is retrieved from storage and decrypted 
using die internal IT key (step 227) in the secure hardware. 
At steps 228-229, the VET is then decompressed, D/A 
converted, and output to the audio amplifier 230. Monetary 
credits are used for decrypting VET envelopes. This ensures 
that payments are received for songs which are provided to 
an IT. As noted above, the VET envelope includes a cost. 
The IT includes an internal store 212 of the monetary credits 
available. The cost of the VET to be decrypted is compared 
with the value in the internal store 212. If the internal credits 
are sufficient, then the amount in the internal store is reduced 
by the VET cost (step 209) and the decrypted VET is further 
processed, as discussed above. If the internal credits are not 
sufficient, then the decryption is terminated (step 210). 
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FIG. 7c illustrates a process for inputting songs from 
sources other than the OSC. The secure hardware is used to 
compress and encrypt a received song as a VET. The VET 
is divided into blocks (step 232), each of which can be 
associated with a cost. The cost and VET data are multi- 
plexed (step 235) and encrypted (step 238) using the VET 
key. The outputted VET envelope is then stored in the IT 
hierarchical storage (step 240) for further processing. 

FIGS. SaSc illustrate the process for increasing mon- 
etary credits for an IT. Monetary credits are increased by 
transferring a monetary certificate to the IT from the OSC. 
The monetary certificate is encrypted to prevent unautho- 
rized modifications. At step 301, the certificate is created 
with an amount and proper keys. The monetary certificate 
(with or without a monetary amount) can also include a new 
VET key to be used for later dated VET transfers. The 
certificate is then encrypted using the internal IT key for the 
IT to receive the credit (step 303). Of course, the transfer of 
money to the OSC from the IT owner can be performed in 
different manners, such as by satellite, keyboard, modem 
and fax to transfer the monetary credits. The certificate is 
then transferred to the IT through an appropriate transfer 
mechanism. Such mechanisms can include direct transmis- 
sions or through transfer of appropriate codes to be entered 
on a keyboard. The internal IT key is used to decrypt the 
certificate (step 322). The certificate is then authenticated by 
comparing the received external IT key to the internal IT key 
(step 325) and comparing the received external serial num- 
ber with the internal serial number (step 331). If there are 
any differences, the certificate is judged to be invalid. When 
a certificate is invalid, the transaction can be aborted, or, 
alternatively, the IT may be disabled (step 327). Serial 
numbers are used to ensure that certificates are not 
counterfeited, duplicated or lost. Each certificate has a serial 
number set by the OSC. The serial number in the IT 
corresponds to the last serial number sent to the IX The 
serial number is initialized in the secure hardware from the 
OSC as discussed above. When each certificate is received, 
the intemal serial number is increased (step 331) by a 
predetermined amount. Typically, serial numbers may be 
increased by one, but other amounts could be used for 
further protection. If the certificate is determined to be 
authentic, then the internal monetary credits are increased by 
the amount of the credits in the certificate (step 333). 

The monetary certificates can also be used to transmit new 
VET keys. When a certificate is received, the VET key is 
compared to the intemal VET key (step 335). If it is 
different, then a new key is being provided. The system then 
stores the VET key along with the date of the certificate. The 
new VET key is used for VETs received after the certificate 
and until the next VET key change is made. Since VETs may 
be stored before being decrypted, the VET keys for various 
dates can be stored in a memory 334 of the secure hardware. 
The certificate can also be used to adjust the block cost for 
creating VETs which are not from the OSC. The internal 
block cost is set to the received external block cost (step 
338). The intemal block cost is used in the VET processing 
as discussed above. Once the certificate has been fiiUy 
processed, the processing ends. 

FIG. 9 illustrates a second embodiment of the music 
distribution system according to the present invention. As in 
the first embodiment, this embodiment includes a global 
music distribution platform 908 which is an operational 
service center. The operational service center 908 can com- 
municate to jukeboxes using a variety of mechanisms. For 
example, communications can be on telephone lines using a 
modem 911, through removable storage media 907, 916, 
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such as diskettes, or through satellite 901 transmissions. inventor of compact disks can be placed in the CD changer. 

With satellite transmissions, songs and other information In addition to selecting songs stored in the memory of the 

can be transferred to a large number of jukeboxes jukebox 927, the jukebox can be programmed to operate the 

simultaneously, reducing the total transfer cost per song. A CD changer through the interface. Thus, if a user desires to 

stand alone/listen only jukebox 927 may be connected to a 5 listen to a song which is located on an existing CD inside the 

satellite receive 919 to only receive satellite transmissions. cD changer, the jukebox will provide a signal to the CD 

It may not have direct communications to the operational changer to select and play the desired song. In order to 

service center 908. Altematively, a listen/talk jukebox 926 operate with the CD changer, information about the CD's in 

may receive songs through the satellite receiver 918 and the changer must be entered into the jukebox. A scanner 929 

may transfer information through a telephone line modem jq can be connected to jukebox for scanning in album covers to 

917. Typically, this connection would be a long distance be displayed during the selection process. A keyboard 930 

telephone connection, which would be expensive for trans- can be used for entering song information, as well as the 

milling songs, but could be used for transferring playing specific location of the CD's in the changer, 

data, which has a much smaller volume. Removable sto^^^^ Having now described a few embodiments of the 

media 916 such as a diskette, c^n be used for commum- 15 invention, it should be apparent to those skilled in the art that 

catmg with a stand alone mail jukebox 925, The songs and ^^e foregoing is merely illustrative and not limiting, having 

the playing data can be transferred by maUmg diskettes from ^^^^ presented by way of example only. Numerous modi- 

the operational service center to the jukebox location where ^^^^^^^ ^^^^ embodiments are within the scope of one 

they are loaded by an operator. ordinary skill in the art and are contemplated as falling 

The distribution costs for music and the coUection costs 20 within the scope of the invention as defined by the appended 

for playing data can be further reduced by use of an operator claims, 

region 902. One of the jukeboxes in the operator region 902 What is claimed is: 

functions as a master jukebox 906. The master jukebox 906 i ^^^^ distribution system for local digital electronic 

operates in a manner similar to the regional operating jukeboxes comprising: 

service centers Rl, R2 of the first embodiment of the 25 * 1 * 1 • 1 j- 1 ui 

.,1 , , J . ™^ 1 1 jj-*- * a central storage location includmg available songs, 

mvention illustrated m FIG. 1. In addition, the master ^ j^.^ and titles* 

jukebox 906 functions as a regular jukebox location. Thus, &■ V j > 

the master jukebox 906 can communicate with the opera- ^ menuing system, said menuing system includes storing 

tional service center 908 through any of the distribution ^ PO^ion of a menu at a local jukebox location, wherein 

types, including telephone line modems 910, removable 30 jukebox location is separate from the central 

storage 907, or satelUte reception 903. In addition, the storage location, and storing a complete menu at said 

master jukebox 906 is connected through telephone line ^^^^ storage location; 

modems 910, 913, 914, 915 to a plurality of slave jukeboxes a communication means between said central storage 

922, 923, 924. Preferably, the slave jukeboxes 922, 923, 924 location and said local jukeboxes, wherein the local 

are located within a local calling region of the master 35 jukeboxes download desired information automatically 

jukebox 906. In this manner, the songs can be distributed during a broadcast from the central storage location; 

less expensively from the master jukebox to the slave and 

jukeboxes. Alternatively, removable storage media 912 can a scheduler for coordinating transmission from said cen- 

be used for transferring songs to slave jukeboxes 920, 921. tral storage location to said local jukeboxes. 

The communications between the slave jukeboxes and the 40 2. A music distribution system for local digital electronic 

master jukebox can also be two way. In this manner, the jukeboxes as claimed in claim 1, wherein said menuing 

information about playing of songs, and the selections for system includes a statistical replacement algorithm for 

new songs can be transferred back to the master jukebox, retrieving additional portions of a menu based upon local 

From there it can be transferred to the operational service accesses to said local jukebox, 

center 908. Although FIG. 9 illustrates a single level 45 3. A music distribution system for local digital electronic 

between the operational service center 908 and the master jukeboxes as claimed in claim 1, wherein said songs are 

jukebox 906, any number of regional operational service placed on said localjukebox based upon user inquiries about 

centers or other master jukeboxes can be used in a hierar- availability. 

chical structure. Since each master jukebox will communi- 4. A music distribution system for local digital electronic 

cate with only a portion of the slave jukeboxes in the system, 50 jukeboxes as claimed in claim 1, wherein the local juke- 

commimications over telephone lines should be sufficient. A boxes initiate communication with the central storage loca- 

single phone line can provide 270 hours of communication tion and said music is retrieved by said local jukeboxes 

per month. Assuming that the transfer of a song lasts automatically based upon actual user preferences at a juke- 

approximately 20 minutes, a single phone line can distribute box location. 

2160 songs per month. The master jukebox 906 could 55 5. A music distribution system for local digital electronic 

provide an average of six new songs per month to 360 slave jukeboxes as claimed in claim 1, wherein said scheduler 

jukeboxes. With this number of songs, each slave jukebox arranges the broadcast of songs simultaneously to a plurality 

may be assigned certain time slots for accessing the master of jukeboxes. 

jukebox. When accessed, the slave jukebox can transfer the 6. A music distribution system for local digital electronic 

playing information to the master jukebox and download 60 jukeboxes as claimed in claim 1, wherein said scheduler 

any necessary songs. delays transmission of music within a requested time frame 

FIG. 9 also illustrates use of the present invention in to improve transmission times and minimize costs, 

connection with current jukebox technologies. Many juke- 7. A music distribution system for local digital electronic 

box operators may already have a significant inventory of jukeboxes as claimed in claim 1, wherein said transmission 

compact disks on which a large portion of the music is 65 occurs automatically for non-interactive updates, 

stored. As illustrated in FIG. 9, a jukebox 927 can have an 8. A music distribution system for local digital electronic 

interface for connecting to a CD changer 928. The existing jukeboxes as claimed in claim 1, wherein said local jukebox 
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includes an advanced payment system to allow automatic 
access to said central storage system. 

9. A method for optimally transmitting music selections in 
a music distribution system comprising: 

maintaining statistics in a digital electronic jukebox, 

regarding a number of times a node in a menu hierarchy 

is reviewed by a user; 
using said statistics to indicate when a node has been 

reviewed a predetermined number of times; 
sending a request automatically for updated music from 

said jukebox to a central storage location, based on said 

statistics determined in said jukebox; 
receiving requested music within a time period specified 

in the request at said jukebox; 
said receiving step further including transmitting music 

from said central storage location to a plurality of 

jukeboxes simultaneously; and 
storing a portion of said menu hierarchy at said jukebox. 

10. A method for optimally transmitting music selections 
in a music distribution system as claimed in claim 9, wherein 
said menu hierarchy includes levels for music types, 
subtypes, albums, and songs. 

11. A method for optimally transmitting music selections 
in a music distribution system as claimed in claim 9, wherein 
said statistics represent actual user preferences at said juke- 
box location. 

12. A method for optimally transmitting music selections 
in a music distribution system as claimed in claim 9, wherein 
said transmitting is coordinated by delaying transmission 
times of a portion of the requested music within a delay time 
period defined in the request and according to a schedule to 
increase transmission efficiency and minimize costs. 

13. A music distribution system comprising: 

a central storage location including available songs, 
graphics and titles; 

a plurality of local computer jukeboxes separate from the 
central storage location; and 

at least one regional storage location separate from and 
communicating with the central storage location and 
the plurality of local computer jukeboxes, the at least 
one regional storage location storing a portion of the 
available songs and transferring available songs to the 
computer jukeboxes. 

14. The music distribution system of claim 13, further 
comprising: 

a first communications system between said central stor- 
age location and said at least one regional storage 
location; and 

a second communications system between said at least 
one regional storage location and each of said plurality 
of computer jukeboxes. 

15. The music distribution system of claim 14, wherein 
said first communications system includes one of a satellite 
transmission system, a telephone line, and a mailed diskette. 

16. The music distribution system of claim 14, wherein 
said second communications system includes one of a 
satellite transmission system, a telephone line, and a mailed 
diskette. 

17. The music distribution system of claim 14, wherein 
said at least one regional storage location includes a master 
jukebox. 

18. A computer jukebox comprising: 

reception means for receiving songs from a central stor- 
age location; 
a memory for storing songs; 
playing means for playing stored songs; 
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an interface for outputting signals to control a compact 
disk changer to select and play a desired song. 

19. The computer jukebox of claim 18, further compris- 
ing: 

^ user selection means for selecting a song stored in one of 
said memory and on a compact disk in an attached 
compact disk changer; and 
means for outputting control signals to said compact disk 

jQ changer through said interface to execute a selected 
song on a compact disk. 

20. The music distribution system of claim 1, further 
including: 

a data structure that relates similar songs, wherein the 
15 similar songs have a high probability of being preferred 
by users of a particular location. 

21. The music distribution system of claim 20, wherein 
the probability is defined by a local jukebox. 

22. The music distribution system of claim 20, wherein 
20 the probability is defined by a central storage system. 

23. The music distribution system of claim 2, wherein the 
local accesses to the local jukebox define a mix of music 
categories in which a percentage of songs for a given 
category is determined by user preferences. 

25 24. Tlie music distribution system of claim 1, wherein the 
scheduler ananges the broadcast of songs automatically 
based on at least one of: user preferences at a jukebox 
location, anticipated use of similar songs which are available 
on the local jukebox, local music menu profiles and songs 

3g automatically transmitted from the central storage location 
to the local jukebox without a request. 

25, The music distribution system of claim 4, wherein the 
music is retrieved in advance of an automatic update based 
on an anticipated use of similar songs which are locally 
accessed songs, local music menu profiles and songs auto- 
matically transmitted from the central storage location to the 
local jukebox without a request. 

26, The music distribution system of claim 1, wherein the 
scheduler accumulates requests for each different song 
within a time period defined in the request, and wherein one 

40 broadcast is performed for the combination of the accumu- 
lated requests. 

27, The method for optimally transmitting music selec- 
tions of claim 9, further comprising: 

broadcasting a list of new available song3 from a central 
45 storage location to a plurality of local jukeboxes; 
downloading said list into a local jukebox; 
downloading requested songs automatically during the 

broadcasting from the central storage location into the 

local jukebox; 
loading credits through payments in said local jukebox; 
decreasing a number of credits corresponding to a mmiber 

of downloaded songs. 

28, The method for optimally transmitting music selec- 
55 tions of claim 9, wherein the music is retrieved from a 

hierarchy of classes of music, wherein the hierarchy is stored 
in its entirety in the central storage location. 

29, The method for optimally transmitting music selec- 
tions of claim 9, further including: 

go deferring transmission of music based on local user needs; 
and 

transmitting music requested based on local user needs 
from said central storage location simultaneously to 
multiple jukeboxes, when requested delivery times 
65 overlap. 

♦ * ♦ * * 
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